\subsection{Entwicklungsbericht}

Eine grunds\"atzliche Frage, die es zu kl\"aren gab, war der Aufbau der Architektur. F. Echtler und G. Klinker \cite{bib:arch} stellen in ihrer Arbeit ein mehrschichtiges Modell einer Multi-Touch Architektur vor. Diese Architekturvorlage wurde als Basis f\"ur die Implementierung herangezogen und brachte einige Vorteile bei der Kapselung der Komponenten.

Bei der Wahl der m\"oglichen Entwicklungsumgebung und der in Verbindung stehenden Programmiersprache stellte das Projektteam mehrere Programmiersprachen gegen\"uber.

Eine M\"oglichkeit war die Entwicklung in Flash zu starten. Da keines der Projektmitglieder Erfahrungen auf dem Bereich der Flash-Programmierung hatte, wurde von Flash sehr schnell Abstand genommen.

Eine weitere Variante w\"are es, die Entwicklung der Software in python vorzunehmen. Da aber wie bei Flash das Projektteam auf keinerlei Erfahrungen zur\"uckgreifen konnte, wurde diese Variante auch sehr schnell verworfen.

Als weitere Programmiersprache wurde Processing beleuchtet. Processing ist eine auf die Einsatzbereiche Grafik, Simulation und Animation spezialisierte objektorientierte, stark typisierte Programmiersprache mit zugeh\"origer integrierter Entwicklungsumgebung. Sie hat den Charakter einer stark vereinfachten Version der Programmiersprache Java und erlaubt es, Interaktionen und visuelle Elemente zu programmieren. Da Processing so stark an Java angelehnt ist, entschied das Projektteam es in die n\"ahere Auswahl mit aufzunehmen. 

Zuletzt wurde die Programmiersprache Java  beleuchtet. Bei der Evaluierung stie{\ss}en die Projektmitglieder auf eine freie Bibliothek tuioZones. Sie beinhaltet eine Implementierung, die mittels Java auf TUIO-Nachrichten reagierte. Des Weiteren fand das Projektteam Codesegmente, die es erlaubten Zonen zu definieren, die verschoben werden konnten. Dies half dem Projektmitgliedern sehr, da ab diesem Zeitpunkt schon ein konkreteres Bild von der Architektur der Software angefertigt werden konnte.

Schlussendlich entschied man sich f\"ur die Implementierung des Backends in der Programmiersprache Java und die Visualisierung in Processing. Verglichen mit der Architekturbeschreibung von F. Echtler und G. Klinker \cite{bib:arch} wurden die einzelnen geschichteten Komponenten wie folgt umgesetzt:

\begin{itemize}
  \item{Reduzierter Widget Layer}
    
    Mit Processing werden die verarbeiteten Daten nur mehr dargestellt. Die Kommunikation mit den darunterliegenden Schichten erfolgt rein f\"ur die Datenbeschaffung.
  
  \item{Interpretation Layer und Teile des Widget Layer}
  
    Das Java Backend umfasse die Verarbeitung der Input Daten. Die Gestenerkennung und die relevanten Regionen sind eng miteinander verbunden und somit wurden diese zwei Schichten nicht getrennt.
    
  \item{Hardware Abstraction Layer und Transformation Layer}

    Mit Hilfe der Software tbeta (Kapitel \ref{section:tools}) wurden diese zwei Schichten zusammengefasst.
\end{itemize}

Nach dem Modell von F. Echtler und G. Klinker \cite{bib:arch} sollte der Widget Layer dem Interpretation Layer die relevanten Regionen zukommen lassen. Diese Informationen wurden jedoch nur im Java Backend Bereich gespeichert. Das Java Backend bereitete die Daten auf, sodass diese nur mehr mit Processing visualisiert werden m\"ussen.

F\"ur die Entwicklung des Spiels wurden mehrere Entwicklungsumgebungen gew\"ahlt. Jedes Projektmitglied verwendete das von ihm pr\"aferierte Entwicklungswerkzeug. 

Ein Projektmitglied verwendete f\"ur die Entwicklung die freie Software Netbeans IDE. NetBeans IDE (oft auch nur NetBeans genannt) ist eine Entwicklungsumgebung, die komplett in der Programmiersprache Java geschrieben wurde und auf der NetBeans Plattform l\"auft. NetBeans IDE wurde haupts\"achlich f\"ur die Programmiersprache Java entwickelt und unterst\"utzt unter anderem C, C++ und dynamische Programmiersprachen. Zus\"atzlich wurden sogenannte Packs entwickelt, die der IDE eine gro{\ss}e Anzahl der Funktionsm\"oglichkeiten bietet. NetBeans ist ein Open-Source-Projekt, das als Plattform f\"ur eigene Anwendungen verwendet werden kann. 

Das andere Projektmitglied verwendete die ebenso freie Software Eclipse IDE. Eclipse ist ein quelloffenes Programmierwerkzeug zur Entwicklung von Software verschiedenster Art. Urspr\"unglich wurde Eclipse als integrierte Entwicklungsumgebung f\"ur die Programmiersprache Java genutzt, aufgrund seiner Erweiterbarkeit wird es aber mittlerweile auch f\"ur viele andere Entwicklungsaufgaben eingesetzt. F\"ur Eclipse gibt es eine Vielzahl von Erweiterungen, sowohl quelloffen als auch von kommerziellen Anbietern.

Die Entwicklungsumgebung f\"ur die Visualisierung war einerseits Processing selbst, anderseits wurde das Spiel direkt aus Netbeans heraus gestartet.

F\"ur die Verwaltung und Versionierung des Source-Codes wurde ein freies Subversion-Repository von GoogleCode verwendet. Dies erm\"oglichte dem Projektteam den Source-Code zentral zu speichern und m\"oglichen Versions-Konflikten gro{\ss}teils zu umgehen. 

\subsubsection{Verwendung von Frameworks/Libraries}
Die bei der Evaluierung gefundene Bibliothek tuioZones diente lediglich als Grundlage f\"ur die Entwicklung. Sie half den Projektmitgliedern den Verarbeitungsprozess der TUIO-Nachrichten zu verstehen. F\"ur das entg\"ultige Spiel wurde eine komplett eingenst\"andige Implementierung angefertigt. Es wurden jediglich Bibliotheken f\"ur das empfangen von TUIO-Nachrichten in das Softwarepaket \"ubernommen(oscP5 , netP5 ). Um im Java auf die Visualisierungskomponenten zugreifen zu k\"onnen, wurde die Processing-Bibliothek core.jar eingebunden.

Im Processing muss nur der kompilierte Java-Code als Bibliothek eingebunden werden. Die Visualisierung konnte mit wenig Processing-Code implementiert werden. Das Kompilieren und Packen des kompilierten Codes erfolgt mittels Ant-Buildscript.

  \subsubsection{Verwendete Tools f\"ur Input-Simulation}\label{section:tools}
  Noch bevor die Entwicklungsphase startete, besch\"aftigte sich das Projektteam mit dem von der Seminarleitung vorgestellten Simulator f\"ur TUIO-Nachrichten, den TUIOSimulator in der Version 12.2.0 \cite{bib:tuio_simulator}. Diese Simulationssoftware simuliert Ber\"uhrungen und erzeugt TUIO-Nachrichten. Leider musste das Team ziemlich schnell feststellen, dass der Simulator es nicht zul\"asst, mehrere gleichzeitige Eingabepunkte zu definieren. Da dies aber eine essentielle Anforderung an die zu entwickelnde Software war, musste nach einer Alternative gesucht werden. Das Projektteam einigte sich darauf, einen MTmini \cite{bib:mtmini} anzufertigen. Ein MTmini ist ein kleines, portables Multi-Touch Eingabeger\"at, das zum Testen von Software und zum Experimentieren mit der Multi-Touch Technologie gedacht ist. Dieser MTmini verwendet Diffused Illumination \ref{section:di} und eine triviale Webcam zum Erkennen der Ber\"uhrungspunkte.
  
  Die erste Version des MTmini wurde aus einem Karton angefertigt. Eine Plexiglasscheibe, \"uberzogen mit herk\"ommlichem Backpapier diente als Touchfl\"ache. Diese Touchfl\"ache war mit der Gr\"o{\ss}e von ca. einem A4-Blatt eher klein gehalten. Dennoch konnten hier erste Erfahrungen mit dem Umgang mit TUIO-Nachrichten gesammelt werden.
  
  Als zweites Input Ger\"at entwickelte das Projektteam einen gr\"o{\ss}eren MTmini. Hierbei handelte es sich um ein h\"ufthohes M\"obelst\"uck eines Projektmitgliedes. Das M\"obelst\"uck war ein umfunktioniertes K\"astchen, bei dem in die obere Abstellfl\"ache ein ca. A3-Blatt gro{\ss}es Loch ges\"agt wurde. In ca. 80cm Entfernung wurde die Kamera angebracht. Bei der Kamera handelte es sich um eine Webcam Trust WB-6250X. Um eine bessere Erkennung der Ber\"uhrung der Tocuhfl\"ache zu erhalten, wurde der eingebaute Infrarotlichtfilter ausgebaut.
  
  Die Vorteile des MTminis kamen schnell ans Tageslicht. Es war dem Projektteam nun m\"oglich, mit mehreren Eingabepunkten gleichzeitig zu arbeiten und zu entwickeln. Dies erlaubte auch eine Bedienung durch mehrere Leute. Auf der gr\"o{\ss}eren Eingabefl\"ache konnte viel genauer gearbeitet werden als auf der kleineren.
  
  Neben all den vielen Vorteilen muss auch auf einen wichtigen Nachteil des MTminis aufmerksam gemacht werden. Leider ist bei der Erkennungssoftware auch die Helligkeit sehr wichtig. Da die Sonneneinstrahlung von Stunde zu Stunde ihre Intensit\"at ver\"andert, ist es w\"ahrend l\"angeren Sitzungen des \"ofteren notwendig, die Kalibrierung der Erkennungssoftware vorzunehmen.
  Dennoch \"uberwogen die Vorteile des MTminis und eine Entwicklung des Spiel konnte erfolgreich abgeschlossen werden.
  
  F\"ur das Erkennen der Ber\"uhrungspunkte am MTmini wurde die Software tbeta in der Version 1.0 verwendet. Sie verarbeitet den Video-Input Stream von der Webcam und verwandelt diesen in Tracking-Daten Output, der an die TUIO-Schnittstelle weitergeleitet wird.
  
  \subsection{Entwicklungsphase}
  
  W\"ahrend der Entwicklung stie{\ss} das Projektteam auf drei wichtige Aufgaben, die es zu l\"osen gab. Die Probleme besch\"aftigten sich mit dem mathematischen Berechnungen und Transformation von Objekten im zweidimensionalen Raum.
  
  Das erste, etwas leichtere Problem, handelte von der Berechnung des Verschiebens von Objekten. Die Fragestellung, die es zu l\"osen gab, war: Wie verschiebt man ein Objekt nur anhand eines Ber\"uhrungspunktes in der Ebene? Nach einigen Versuchen und etwas Recherche konnte das Problem wie folgt gel\"ost werden. Ausgangspunkt ist ein Ber\"uhrungspunkt auf dem Objekt. Der Vektor von diesem Ber\"uhrungspunkt zu einem bestimmten Eckpunkt muss zwischengespeichert werden. Beim Verschieben des Ber\"uhrungspunktes muss zum verschobenen Punkt dieser Vektor hinzuaddiert werden, um den neuen Eckpunkt zu erhalten. Vom neuen Eckpunkt aus muss nun das zu zeichnende Objekt gezeichnet werden.
  
  Das zweite Problem behandelte die Frage, wann ein Ber\"uhrungstpunkt am Tisch innerhalb eines Objektes ist oder nicht. Bei einem quadratischen K\"orper ist dies leichter auszurechnen als bei einem Rechteck. Nach anf\"anglich falschen Berechnungen konnte das Problem identifiziert und gel\"ost werden. Man ging davon aus, dass ein Ber\"uhrungspunkt nur dann innerhalb des Objektes ist, wenn er von den Seitenkanten maximal die Breite und von den oberen und unteren Kanten maximal die H\"ohe entfernt ist. Hierf\"ur ist die Hesse`sche Normalform anzuwenden. Diese Art der Berechnung zeigte sich als sehr zuverl\"assig und l\"oste das Problem.
  
  Das letzte, zeitintensivste Problem, besch\"aftigte sich mit der Fragestellung, wie Objekte im 2-dimensionalen Raum gedreht werden k\"onnen. Als Vorbedingung, dass ein Objekt gedreht werden konnte, musste erst festgestellt werden, ob das Objekt zwei Ber\"uhrungspunkte vorwies. War dies gegeben, so wurden diese Ber\"uhrungspunkte, der Winkel der Geraden zwischen den zwei Ber\"uhrungspunkten zur X-Achse sowie der Vektor vom Mittelpunkt dieser Geraden zu einem bestimmten Eckpunkt gespeichert. Nach dem Drehen der zwei Ber\"uhrungspunkte wurde erneut der Winkel der Geraden zur X-Achse berechnet. Der zuvor berechnete Vektor vom Mittelpunkt der Geraden zum Eckpunkt wurde vom neuen Mittelpunkt ausgehend um die Differenz der beiden Winkeln transformiert und somit erhielt man die neuen Koordinaten des Eckpunktes. Die Steigung der Geraden zur X-Achse erh\"alt man mit ArcTan und zum Transformieren eines Vektors ben\"otigt man die aktive Drehmatrix. Durch diese Art von Berechnung konnte sogar das Verschieben mittels Zwei Ber\"uhrungspunkten implementiert werden. 
  
  Weiters muss darauf aufmerksam gemacht werden, dass Processing nur Bibliotheken einbinden kann, die mit Java in der Version 1.5.x kompiliert sind.
  
  Die anfangs verwendete Simulationssoftware f\"ur TUIO-Nachrichten, TUIO-Simulator, ist in den Bereichen der Ber\"uhrungspunkte unvollst\"andig. Leider ist es nicht m\"oglich, einen Ber\"uhrungspunkt an einer bestimmten Stelle zu halten. Die Simulationssoftware schickt keine ``Alive''-Nachricht des Ber\"uhrungspunktes. Somit wird ein Ber\"uhrungspunkt, wenn er an einem Punkt verweilt, obwohl die Maustaste gedr\"uckt bleibt, gel\"oscht. Bei anschlie{\ss}endem Verschieben wird ein neuer Ber\"uhrungspunkt erzeugt. Gel\"ost wurde das Problem mit dem Bau eines MTminis, bei dem es m\"oglich war, die Ber\"uhrungspunkte an einem bestimmten Punkt ohne diesen zu bewegen, aktiv zu halten.
  
  \subsection{Endprodukt}
  
  Nach einigen theoretischen Erl\"auterungen bez\"uglich der Entwicklungsphase, m\"ochten wir nun das Endprodukt beleuchten.
  
  \begin{figure}
    \centering
    \includegraphics[width=13cm]{Grafiken/spielflaeche_mit_karten.png}
    \caption[Spielfl\"ache mit K\"artchen]{Spielfl\"ache mit K\"artchen}\label{fig:spielflaeche}
  \end{figure}
  
  Beim Starten der Applikation wird die Spielfl\"ache (Abbildung \ref{fig:spielflaeche}) mit einigen K\"artchen darauf dargestellt. Abh\"angig, wieviele Kategorien (Abbildung \ref{fig:kat1} und \ref{fig:kat2}) es an Spielkarten gibt, werden auch mehrere Karten dargestellt. Je Kategorie haben wir eine Darstellung von 12 Karten gew\"ahlt, was soviel wie 6 ``fertige'' Puzzles bedeutet. Diese Konstante kann nach Bedarf hinauf oder herabgesetzt werden. Wenn mehrere Kategorien vorhanden sind, dann ist es sinnvoller, diese Konstante herabzusetzen, bei weniger, ist diese zu erh\"ohen, da sonst entweder zu viel oder zu wenige Karten am Tisch vorhanden sind. 
  
  Durch die Verf\"ugbarkeit von mehreren Kategorien hat das Schulkind die M\"oglichkeit, nur eine gewisse Type an Karten zusammenzuf\"uhren. Zur Zeit ist noch keine strikte Trennung der Kategorien vorgesehen. Das Kind kann auch w\"ahrend eines Durchganges die Kategorien je K\"artchen selbst w\"ahlen. Es liegt somit im eigenen Ermessen der Kinder, welche Spielweise sie bevorzugen.

  In der jetzigen Version haben wir bereits zwei Kategorien bereitgestellt. Diese Kategorien beinhalten jeweils unterschiedliche Typen von Karten. 
  
  Die erste Kategorie (Abbildung \ref{fig:kat1}) beinhaltet K\"artchen, auf denen jeweils ein Wort geschrieben ist, aber auch die H\"alfte des Symbol des Wortes. Den p\"adagogischen Vorteil, den wir bei dieser Kategorie sehen ist, dass das Kind noch nicht zwingend lesen k\"onnen muss. Vorteilhaft w\"are jedoch die Kenntnis der Buchstaben bzw. wie diese ausgesprochen werden. Kennt das Schulkind das Wort auf dem K\"artchen noch nicht, so muss es die andere H\"alfte des Symbols suchen. Kann das Kind jedoch weder das Wort lesen noch das Symbol richtig gedanklich konstruieren, so muss es die anderen K\"artchen durchsuchen, welche H\"alfte des Symbols die Fortsetzung des gesuchten Symbols ist. Durch diese Hilfestellung der Symbole verbinden Kinder das Wortbild mit dem Symbol und wissen dadurch, was das Wortbild bedeutet. Dies erfordert noch nicht zwingend, dass sie das Wort auch lesen k\"onnen. Gerade am Anfang der Volksschulzeit ist auch das Erlernen von Wortbildern sehr wichtig. Wie in Abbildung \ref{fig:kat1} klar zu erkennen ist, spielt hier eine wichtige Rolle, wie die K\"artchen zusammengef\"uhrt werden. Es gibt nur eine Kombination, wie die Zusammenf\"uhrung einen Sinn ergibt.
  
  \begin{figure}
    \centering
    \includegraphics[width=7cm]{Grafiken/kat1.png}
    \caption[K\"artchen mit zerschnittenen Symbolen]{K\"artchen mit zerschnittenen Symbolen}\label{fig:kat1}
  \end{figure}
  
  Bei der zweiten Kategorie (Abbildung \ref{fig:kat2}) haben wir K\"artchen gew\"ahlt, bei denen entweder ein Symbol oder ein Wort zu sehen ist. Wenn ein Kind eine Symbolkarte vor sich liegen hat, muss es das Symbol interpretieren, \"uberlegen, was das Symbol darstellt und das interpretierte Wort am Tisch suchen. Bei diesem Suchvorgang muss das Kind unbewusst einige andere W\"orter lesen bis es das eigentliche richtige Wort gefunden hat. Da es keine Relevanz spielt, ob zuerst das Symbol ist oder zuerst das Wort steht, k\"onnen diese K\"artchen an der rechten und er der linken Kante zusammengef\"uhrt werden. Diese Type von K\"artchen ist f\"ur Kinder schwieriger, da sie wirklich die W\"orter lesen m\"ussen, damit diese richtig zusammengef\"uhrt werden k\"onnen. Durch die erh\"ohte Schwierigkeit sollte man beim Einsatz diese Kategorie die Lesekenntnisse der Kinder in Betracht ziehen.
  
  \begin{figure}
    \centering
    \includegraphics[width=7cm]{Grafiken/kat2.png}
    \caption[Ein K\"artchen mit einem Symbol, das Andere mit einem Wort]{Ein K\"artchen mit einem Symbol, das Andere mit einem Wort}\label{fig:kat2}
  \end{figure}
  
  Die Aufteilung, wie die K\"artchen zusammengef\"uhrt werden k\"onnen haben wir nur f\"ur die Entwicklung des Prototypens in unterschiedliche Kategorien gelegt. Programmtechnisch haben wir jedoch auch unterschiedliche Typen von Karten innerhalb einer Kategorie vorgesehen. Bei der Fragestellung, wie man die Kodierung, wie ein Puzzle zusammengesetzt werden kann, f\"ur Lehrpersonal zug\"anglich implementiert, haben wir uns f\"ur die Verwendung von Namenskonventionen entschieden. Diese Namenskonventionen bieten parallel noch die M\"oglichkeit der Identifizierung der ``Partnerkarte'' des Puzzles. Die genaue Namenskonvention ist aus Listing \ref{listing:naming} zu entnehmen. Wenn die Lehrperson eine Kategorie anlegen will, muss diese einfach einen Ordner mit Bildern lt. Namenskonvention hinzuf\"ugen. Beim n\"achsten Programmstart ist die neue Kategorie vorhanden und die K\"artchen werden dargestellt.
 
  \begin{lstlisting}[frame=trBL,caption=Namenskonventionen f\"ur die ``Partnerkarten''-Bestimmung,label=listing:naming]{}
/**
 * <<FLAG>><<TITLE>><<ID>>.jpg
 * 
 * <<FLAG>> ..... "~" wenn die Karte beidsteitig zusammengesetzt werden kann
 * <<TITLE>> .... eindeutiger Name innerhalb einer Kategorie
 * <<ID>> ....... "A" oder "B" dient zur Referenzierung der "Partnerkarte"
 */
public class ImageFilter implements FileFilter {
		public boolean accept(File pathname) {
			String name = pathname.getName();
			// (encoding is set to .jpg)
			return name.endsWith("A"+ending) || name.endsWith("B"+ending);
		}
	}
  \end{lstlisting}
  
  Nachdem das Programm in seiner Ausgangssituation ist, k\"onnen die Sch\"uler zu spielen beginnen. Die Kinder suchen am Tisch zwei zusammenpassende Karten und f\"uhren diese zusammen. Um das fertig zusammengesetzte Puzzle abzulegen und um ein neues zu erhalten, muss es in die Ablagefl\"ache gezogen werden(Abbildung \ref{fig:ablage}). Die Ablagefl\"ache kann bis zu neun Puzzles fassen, danach wird eine Animation abgespielt. Nach Beendung der Animation ist die Ablagefl\"ache wieder leer und das Kind kann mit dem Symbole-W\"orter Puzzle fortfahren. Da die Spieler rund um den Tisch verteilt sind, muss darauf achtgegeben werden, welche Ausrichtung die Ablagefl\"ache hat. Somit ergibt sich, dass die Fl\"achen an jeweils zwei Tischkanten vertikal bzw. horizontal stehen m\"ussen, aber auch die Puzzles je nach Sichtweise in der Reihenfolge zuerst die Spalte ganz links, dann in die Mitte und zum Schluss die ganz rechts eingef\"ugt werden.
  
  Ein wichtiges Feature, das von unserem Produkt unterst\"utzt wird, ist die Erkennung der Gesten. Gestenerkennung erm\"oglicht es dem Menschen einen Computer anzusprechen und mit diesem auf nat\"urliche Art und Wiese zu interagieren. Durch das Erkennen der Gesten der Spielenden kann direkt ins Spielgeschehen eingegriffen werden. Spielkarten k\"onnen verschoben und rotiert werden.
  
  \begin{figure}
    \centering
    \includegraphics[width=4cm]{Grafiken/ablage.png}
    \caption[Ablagefl\"ache mit fertigen Puzzles]{Ablagefl\"ache mit fertigen Puzzles}\label{fig:ablage}
  \end{figure}
  
  Um das visuelle Feedback f\"ur die Kinder zu verbessern, werden an den Ber\"uhrungspunkten am Tisch kleine graue Kreise gezeichnet. Damit erh\"alt man einerseits R\"uckmeldung, ob der Multi-Touch Bildschirm richtig kalibriert ist und der Ber\"uhrungspunkt halbwegs in der N\"ahe des gezeichneten Punktes ist. Andererseits liefert der gezeichnete Punkt auch Gewissheit, dass der Ber\"uhrungspunkt auch dem gewollten Objekt zugeh\"orig ist.
  
  Das reine Verschieben wird dann vorgenommen, wenn genau ein Ber\"uhrungspunkt innerhalb eines K\"artchens bzw. Puzzles ist. Beim Verschieben ist kein visueller Effekt hinterlegt, sondern nur der graue Punkt ist zu sehen. Beim Rotieren von K\"artchen bzw. Puzzles sind genau zwei Beru\"hrungspunkte innerhalb des Objektes notwendig. Neben den zwei grauen Punkten ist auch ein roter Kreis genau zwischen den zwei grauen Punkten zu sehen. Dieser rote Kreis markiert den Rotationspunkt, um den sich das Objekt rotiert. Er soll auch Aufschluss geben, ob das Objekt rotiert werden kann. Der rote Kreis w\"are nicht notwendig, wenn das Objekt nur an der aktuellen Position rotieren werden k\"onnte. Da wir aber vorgesehen haben, auch w\"ahrend dem Rotieren, das Objekt verschieben zu k\"onnen, ist dieser Punkt sehr hilfreich. (Abbildung \ref{fig:touch_rotate})
  
  \begin{figure}
    \centering
    \includegraphics[width=6cm]{Grafiken/touch_rotate.png}
    \caption[Verschieben und Rotieren von K\"artchen]{Verschieben und Rotieren von K\"artchen}\label{fig:touch_rotate}
  \end{figure}
  
  Um das Zusammensetzen von K\"artchen zu erleichtern haben wir einen magnetischen Effekt zwischen zwei zusammengeh\"origen Karten implementiert. Da die kleinst m\"ogliche zu verschiebende Distanz 1 Pixel betr\"agt und diese Genauigkeit mit dem Auge oft schwer zu erkennen ist, werden bei einer von uns definierten Entfernung von 15 Pixel der Eckpunkte die K\"artchen ``zusammengezogen'' und somit zu einem Puzzle fusioniert. Dies beschleunigt den Spielfluss enorm, da nicht aufw\"andig versucht werden muss, die Karten zusammenzuf\"uhren.
  